The invention relates to apparatus and methods for client access to information stored in an open directory and, in particular, to a framework for open directory extensibility that enables pre-processing and post-processing of operations used to access the information stored in the open directory.
Directory servers known in the art store information in connected hierarchical tree structures. Information records held in a directory are only limited by rules imposed by a directory schema that govern any particular record type. Pointers can be set between a point in the directory and any other point in the directory. Although the rules imposed by the directory schema perform general directory data validation, the validation checks are not comprehensive in current directory server implementations.
A Lightweight Directory Access Protocol (LDAP) is an emerging Internet Engineering Task Force (IETF) standard which is gaining popularity in the industry as a mechanism by which to access a directory. The IETF LDAP specification itself provides a protocol for accessing information held by a persistent store, such as a directory.
A schema specification defines managed objects and attributes. These objects and attributes are specified through a data dictionary that provides a standard set of object classes. An object belongs to one or more object classes which define the attributes of the object. Generally, the schema is extensible by deriving other object classes (e.g. by modifying existing object classes and/or adding new object classes) according to methods known in the art so that the schema specification may be tailored to specific requirements.
The IETF standard provides some facilities to assist interoperability of certain network device management and network service management functionalities. However, an implementer using LDAP is also provided with extensions enabling the specification of vendor-specific schema, and an Application Program Interface (API) which may be used to access the elements of that vendor-specific schema. Once an LDAP schema is published, other implementers have a common mechanism by which that schema may be accessed, for example, by service provisioning, billing, and/or management applications. Various vendors are developing LDAP schema specifications to provide an API which their customers may use to integrate the vendor""s equipment and services into the customer""s internal service provisioning, management, customer care, billing solutions, and the like.
There are a few areas in which the IETF has either just begun to realize, or has not yet begun to realize the need for LDAP standardization. Such areas are schema validation and LDAP message processing.
LDAP message processing mechanisms can provide means by which schema providers may deliver code that: ensures that updates to a directory information tree are consistent with syntactic and semantic checks which are required for maintaining integrity of information stored in the directory; and perform any necessary side-effect changes which may be required as a result of any particular information access action in providing a service. For example, the deletion of one object may require a cascade of associated changes in other objects. A standardized LDAP message processing mechanism is particularly important for situations where it is desired to provide an LDAP schema and the LDAP protocol as an API for other services. If the schema provider cannot provide the code to enforce consistency checks and required side-effect processing, then it becomes more likely that the information stored in a directory will lose integrity, with unpredictable results. Typically in providing a service a prescribed behavior is specified in processing information access messages. Some of this prescribed behavior can be provided via a designed schema description and other prescribed behavior can be provided via specific execution code.
Some of the current LDAP directory server vendors have addressed the need for schema validation through proprietary APIs in their directory server products. In order to provide multi-vendor LDAP server support, this requires that vendors provide LDAP clients coded to support the differences across all vendor products, as well as support for each vendor""s proprietary API set. Moreover, LDAP clients need to have knowledge of the combined schema across all vendors.
Generic (i.e. directory independent) solutions have been proposed which monitor LDAP requests between clients and a directory server, providing access to a directory, to provide directory vendor neutral validation. An example of such solutions includes the LDAP Trigger Access Process Gateway (LTAP gateway) recently proposed by Lucent/Bell Labs. This proposal teaches the use of a xe2x80x9ctrigger gatewayxe2x80x9d implementing a proprietary SQL database-based trigger mechanism providing a schema validation limited to proceed/do not proceed decisions. Lucent/Bell Labs are currently seeking patent protection for their solution.
Other related art is described in U.S. Pat. No. 5,983,234 entitled METHOD AND APPARATUS FOR GENERICALLY VIEWING AND EDITING OBJECTS, which issued Nov. 9, 1999 to Tietjen et al.; and U.S. Pat. No. 5,893,107 entitled METHOD AND SYSTEM FOR UNIFORMLY ACCESSING MULTIPLE DIRECTORY SERVICES, which issued Apr. 6, 1999 to Chan et al.
Access to information stored in a central directory server is enabled via a distributed data network, including intranets (local area networks) and internets (wide area networks), from remote client computers executing LDAP aware client software applications. The current implementations, such as the ones mentioned above, teach that the schema be partly enforced by the LDAP client application and partly by the directory server. The more reliance there is on proprietary solutions, such as the ones mentioned above, the greater an overhead created for a user of provided services in keeping up-to-date with the development of the proprietary solutions.
The problem stems from the fact that access to centrally stored information is provided on different vendor directory servers. The complexity of the data access for service offerings provided on multiple directory servers is increased if each directory server is provided by a different vendor. Directory server vendors are not necessarily service providers. In a competitive environment, various client applications may be required to enable access to a wide range of information. Not only are those various client applications necessary, they also need to be kept up-to-date. Upgrading the various client applications, at different times, to different versions, leads to a high overhead due to financial outlay and time required.
There is therefore a need to provide a framework for open directory extensibility that permits directory independent information access such that directory servers and client applications may be independently developed and maintained.
It is an object of the invention to provide a framework for open directory extensibility that permits directory independent information access.
It is another object of the invention to provide methods and apparatus for processing directory access messages according to a prescribed process.
It is another object of the invention to enable a schema specification to be implemented and enforced through schema validation in an interoperable manner independent of an underlying directory server implementation.
It is a further object of the invention to enable the implementation of schema consistency checks once and enforcement of the schema specification against all directory client access.
It is a further object of the invention to enable a single entity to validate LDAP messages according to a schema description in a layer interposed between LDAP clients and a directory server.
It is yet another object of the invention to enable a single entity to process directory messages according to a specification defining side-effects, in a layer interposed between directory clients and a directory server.
The invention therefore provides a framework for open directory extensibility that includes first and second messaging entities. The first messaging entity is adapted to send and receive directory messages sent to or received from a directory client. The second messaging entity is adapted to send and receive directory messages sent to or received from a directory server. The framework also includes a directory message decoding engine (decoder) adapted to at least partially decode directory messages received by the first and second messaging entities, and a directory message encoding engine (encoder) adapted to encode LDAP messages. At least one module associated with the framework is adapted to process directory messages based on information conveyed in the message so that an integrity of information stored in the directory is maintained.
The framework in accordance with the invention is preferably a Lightweight Directory Access Protocol (LDAP) Validation Proxy (LVP). The LVP is adapted to enable directory-independent message processing of LDAP messages exchanged between an LDAP client and an LDAP directory. The LVP comprises messaging entity adapted to receive and send LDAP messages to and from the LDAP client and adapted to send and receive LDAP messages to and from the LDAP directory; an LDAP message decoding engine (decoder); an LDAP message encoding engine (encoder); and at least one module adapted to process LDAP messages. The LVP further comprises a decision engine adapted to selectively activate the at least one module in processing LDAP messages. The LVP is adapted to intercept LDAP messages exchanged between the client and the directory. The messaging entity may comprise first and second messaging entities, the first messaging entity being adapted to exchange messages with the LDAP client, and the second messaging entity being adapted to exchange messages with the LDAP server.
According to another aspect of the invention, a method of processing LDAP messages exchanged between an LDAP client and an LDAP directory is provided. The method comprises several steps. At least one message exchanged between the client and the directory is intercepted. The intercepted message is at least partially decoded. Prescribed processes are selectively executed against the intercepted message based on information conveyed in the message. And, the LDAP message is selectively forwarded on completing at least one prescribed process based on a success level of the completion of the prescribed process.
With respect to the success level of the completion of the prescribed process, on detecting an error in processing an LDAP message, an LDAP message containing information about the error is encoded and forwarded towards the LDAP client.
On successfully processing the intercepted LDAP message, the intercepted LDAP message is forwarded. If an error is detected in an intercepted LDAP request message, the message may be modified. The modified message is likewise encoded and forwarded.